Уважаемые представители оргкомитета!

Выполняя просьбу Александра о наиболее подробном описании темы и с учетом вопросов по докладу Минска, многое (не все) написано не в формате тезисов, а в формате доклада и с заметками для слайдов (курсивом). Но, конечно, это не окончательный доклад.

Если читать долго (много буквов!) - сообщите, напишу короче.

Методика выработана для крупной многофункциональной корпорати вной системы, состоящей из нескольких подсистем (учетных, транспортно-логистических, отчетных) и обеспечивающей интеграцию Корпорации с клиентами и партнерами.  Характерна сложная зависимость и влияние информационных объектов и операций по ним на другие информационные объекты/операции как внутри одной подсистемы, так и другие подсистемы и системы Корпорации и внешние системы. Приостановка работы системы является по определению недопустимой. Существенно: некоторые проектные документы (Альбомы ТФФ - Альбомы требований к интерфейсам обмена), которые готовим мы в рамках проектных работ, Заказчик передает владельцам и разработчикам внешних систем за строго определенное время до начала эксплуатации версии, для того, чтобы внешние системы успели разработать и установить новую версию своего ПО.

По заявкам, поступающим от Заказчика (на основании изменений к нормативно-правовых актов (далее - НПА, проекты НПА) или для оптимизации работ) в системе учета JIRA регистрируются доработки для каждой подсистемы отдельно в разрезе заявки и подсистемы. После предварительного анализа и определения трудозатрат и в соответствии со сроком вступления в действие НПА доработки включаются в версию, передаваемую Заказчику к заранее определенной дате. Версия содержит изменения по всем ПО в зоне ответственности Исполнителя. Доработки, по различным заявкам Заказчика (имеющие разные основания для включения в версию), входящим в одну версию, часто затрагивают  одну и ту же функциональность или влияют на смежные функции системы.  Т.е. в версии могут содержаться разные доработки, влекущие изменение одних и тех же функций одного и того же документа.  Но в процессе работ по доработкам версии от Заказчика могут поступить изменения к проектам НПА, поступившим первоначально или перенос сроков вступления в действие НПА или новые заявки (которые нужно реализовать в те же сроки), влияющие на ту же функциональность.

Система достаточно большая, сроки проектирования, разработки, подготовки проектных документов очень жесткие. Зачастую изменения проектов НПА поступает уже после начала не только проектирования, но и разработки. Поэтому отследить все изменения в оперативном режиме, вовремя перепроектировать, передать в разработку по всем подсистемам и не сломать решения по доработкам, связанным с другими заявками Заказчика, но по этой же функциональности - задача не совсем простая. При этом проектную документацию нужно передать в установленные сроки по версии и строго описывающую доработки с учетом поступивших изменений.

Количественно по одной версии (периодичность версий - 2-3 месяца):

- доработок в версии по одной подсистеме: 150-250;

- изменяемых интерфейсов - 50-70;

- изменяемых подсистем: обычно 3, бывает до 6;

- (продумать еще количественные показатели).

Мой рассказ о том, как мы формируем требования к интерфейсам обмена на основании доработок, контролируем синхронность функциональных изменений в разных подсистемам (учетной, транспортной, отчетной) и по связанной функциональности.   

Что нам помогает:

1. Договоренность с Заказчиком о сроках поступления заявок и включении доработок в версию. Конечно, сроки далеко не всегда выдерживаются в т.ч. по причинам, не зависящим от Заказчика.  

2. Инструментарий

2.1. JIRA с высокой степенью кастомизации, единый подход:  

– требования НПА/запросы Заказчика, связь НПА и доработок;

- доработки в разрезе подсистем ПО;

- интерфейсы обмена (ТФФ) и Альбомы, содержащие их описание;

- обращения, ошибки.

Настроены типы связей и стараемся их отражать.

Показать описание доработки.

2.2. Subversion, хранилище документации:

- поддержка версионности;

- структуризация хранения документов;

- обязательность использования;

- централизованное решение для распределенной команды.

Показать структуру Альбома ТФФ, версионность, ревизии.

2.3. Система ведения требований к интерфейсов обмена (ТФФ), единое хранилище состояния интерфейсов (ТФФ), программы формирования Альбома с учетом отражения артефактов в разных разделах Альбома и контроля непротиворечивости. Хранимые значения:

- наименование, назначение, маршрутизация;

- мнемоника, тип данных, длина;

- комментарии (условия контроля реквизита в ПО);

- версия ТФФ, дата начала действия версии, дата окончания действия предыдущей версии,

- шаблон, пример.

Особенности изменения версионности ТФФ.

3. Методика, обязательная к выполнению, разработки для внутреннего использования:

- регистрация сущностей в JIRA;

- контроль взаимосвязанных элементов, синхронизация;

- разнообразные отчеты, контроль выполнения.

Показать зависимости функциональности ПО и изменений интерфейсов.

Пример зависимости изменения интерфейса и ПО.

Показать связи отражения изменений ПО и интерфейсов на разных этапах работ с указанием зоны ответственности бизнес анализа, системного анализа, разработки.  

Показать схему ЖЦ доработок этапов анализа и проектирования с  указанием точек контроля:

- полнота регистрации доработок по подсистемам, наличие зарегистрированных изменений интерфейсов;

- включение доработок в версию, изменений интерфейсов в ближайшую версию Альбома ТФФ;

- проверка изменяемых функций ПО по доработкам и изменяемых интерфейсов;

- подготовка бизнес требований по изменяемым интерфейсам;

- согласование бизнес требований внутри бизнес аналитиков по смежным функциям ПО;

- внесение изменений в систему ведения ТФФ;

- формирование Альбома ТФФ;

- согласование Альбома со стороны бизнес аналитиков, системных аналитиков (технических архитекторов) всех подсистем;

- согласование с Заказчиком, через Заказчика - с разработчиками внешних систем.

При поступлении новых заявок от Заказчика, изменении ранее поступивших, поступлении внутренних и/или внешних замечаний к интерфейсам обмена весь цикл выполняется в полном объеме, с обязательным отражением изменений в JIRA, проверкой доработок (при необходимости - их корректировкой), внесением изменений в систему ведения ТФФ, формирования Альбома ТФФ, обязательным пересогласованием.

Автоматизация позволила быстро вносить изменения и переформировывать Альбом, исключить ручное дублирование одних и тех же сведений в разных разделах Альбома (и соответственно, технические ошибки, особенно по срочным изменениям Альбома перед самой публикацией). И конечно, снижение трудозатрат, снижение стрессовости работ.   

Также можно рассказать и про автоформирование смысловой части ТЗ. Но не будет ли это много для 40-минутного доклада? Чтобы не получилось как в Минске - элементарно не хватило времени и доклад получился скомканный и непонятный. 

Формат выступления - блиц-доклад или круглый стол (если будет желание публики).

Возможно изменение лектора или ведение доклада с содокладчиком (ФИО укажу позже).

Рассматриваем показатели назначения к уже разработанной и эксплуатируемой системе.

Как правило, показатели назначения определны при разработке и не изменяются в процессе изменений функциональности.

Т.е. в соответствующих разделах ТЗ указываем - изменений не требуется (стандартной фразой).

Нобывают случаи, когда не рассмотренное влияние показателей назначения может пагубно  сказаться на работоспообности системы. 

Деление показателей назначения на:

- функциональные

- Технологические

- Технические

Рассматриваемые вопросы:

- Как избежать случаев, когда показатели назначения изменяются, а мы отделались стандартной фразой. 

- Как эффективно оценить показатели назначения (рекомендации).

- Как не преувеличить объемы бедствия.

- Всегда ли аналитик имеет возможность оценить показатели назначения.

- Какие именно показатели назначения входят в зону ответственности аналитика.

- Какие показатели назначения не входят в зону ответственности аналитика и кто отвечает за них. 

- Где и как должны быть отражены показатели назначения.

- Место работ по показателям назначения при работах аналитиков по шаблонам проектирования. 

Презентация доклада направлена 18.06.2015 почтой.

Поговорим о общем опыте постановки задачи на проектирование интерфейса.

Какие документы помогают проектировщикам в работе? Кто их может готовить? Должны ли аналитики прикладывать скетчи к документам? Нужно ли вообще разговаривать с проектировщиком о задаче?

Теория ограничений как основная схема для бизнес-анализа

Часто заказчики хотят "нечто необычно специфическое" за свои деньги несмотря на рекомендации аналитиков. В результате получают проблемы. Причем известно кто оказывается виноватым. :) Большинство алгоритмов бизнеса, и в частности инфорамационных систем, отработаны годами или имеют аналоги. Поэтому новизна должна, как минимум настораживать. Появляются однако нечто совершенно новое, но и оно могут быть проверены на простотые критерии "как это позволяет компании зарабатывать больше денег?" "как это снижает связанный капитал или операционные расходы?". Такой подход сейчас дипломатично назывется протипирование или лин-стартапы. 
В докладе я хочу поделиться, чем отличается то "что нужно сделать?" от того, "как это сложно сделать?" Обычно их путают. 
А также некоторые подходы, как презентовать свои решения, чтобы отказать заказчику и убедить его, как делать не надо. 

Почему хорошая разработка это не всегда рост фирмы? 
Если один аналитик стоит 100-150 тыр а команда 500-1000 тыр, очевидно, что неплохо бы пилить только выгодные фичи. Как посчитать?

По жизни оказывается, что на роли аналитиков ставят не очень квалифицированных людей, а квалифицированные быстро теряют квалификацию потому, что нужно много задач и разных областей, много общения с коллегами из других фирм. В этом случае можно быстро набирать опыт. 

Другими словами текущая схема разделения труда обуславливает, что самые главные те кто на виду - программисты. Но они только часть схемы. Что они будут делать зависит от тех кто скажут, что надо делать. А вторым нужен хороший обзор и метазнание, чтобы заворачивать умников сделать новую "загогулину". Либо выводить бизнес-анализ в аутсорс и отдельную фирму и там накапливать компетенции. 

Бизнес идея, как яйца фирмы

Собственников, которые заказывают музыку, обычно интересует не прибыльность, а стабильность и защита бизнеса. В то же время прозрачность бизнес-процессов и система показателей создает большие риски смены собственников. (В своё время для меня, как бизнес-аналитика - это было достаточно шокирующей информациоей.) Отсюда такой низкий спрос на "эффективность" и аналитику. И обычно ее заказыват, когда хотят её продать или вывести на IPO.

Главное - чтобы никто не отобрал. Эти вопросы решаются обычно силовыми методами: разведка, контразведка, экстрасенсы и юристы. Можно ли защитить бизнес по другому? Создать такою идею, которую не нужно скрывать, но скопировать сложно.

Известный факт, что труднее всего копируются огранизационная эффективность. Это касается обычно зрелости моделей управления, качества коммуникации и вовлеченности. Простые вещи, типа отельных бизнес-процессов копируются легко. А что не копируется в приниципе? Или что поздно копировать, когда уже понятно? Что это?

Бизнес идея - это некий набор правил, котрые генерируют поток задач быстрее остальных. Правильнее сказать не генерирует, а распаковывает.  Разумеется этот поток задач редко отделим (отчуждаем) от людей, которые родили эти идеи и правила. В виде раелизации это очень похоже на тайм-менеджмент. Представьте себе удаленную команду, которая генерирует поток задач фирмы. Т.е. просто стратегию разрабатывает, но и осуществляет трекинг ткущих управленческих задач.

Даже, если у вас украли идею, но никто быстрее вас ее не сможет реализовывать. Почему? Потому что только эта команда (яйца фирмы) знает кому и что говорить, как настраивать контроль и т.п.
Это не отчуждается от них. Просто по-другому организован процесс управления. 

Последний раз я беседовал с руководителем франчайзиговой сети. (Все в курсе, что франчайзи могу клепать новые бизнесы, как автомат. Но что-то у них не получается.) Я задавал вопрос, как обычно в духе теории ограничений: "А что мешает вашему бизнесу расти? Где ограничение?" Он отвечал, что ограничение - это мозги. Не понятно конечно, что такое "мозги" и что делать с ними. Я думаю, что речь идет о способности передавать не только знания и навыки, а передвать идеи и вовлеченность. Кстати "Гарднер" и "Хьюит" утверждают, что наибольшую корреляцию из всех измерямых параметров с прибыльностью фирмы, а значит и с востребованостью всего "аналитического" что с этим связано, имеет вовлеченность руководителей компании.

Мой доклад про глубинные причины, про тененции бизнес-аналитики и про то как на этом можно заработать, не погружаясь в наиболее сложный процесс обучения-образования-убеждения достаточно твердолобых людей. В общем: собираем все проблемы, которые вас волнуют и находим наиболее изящное решение. Кто хочет может поучаствовать в этом сумашествии, не только в ходе доклада.